Downstream device service latency reporting for power management

ABSTRACT

For one disclosed embodiment, a transition from a first state to a second, different state for at least a portion of a downstream device may be identified. The first and second states may correspond to different levels relating to activity for at least a portion of the downstream device. Data corresponding to a service latency may be transmitted to an upstream device in response to the identified transition for one or more upstream devices to manage power based at least in part on the service latency. Other embodiments are also disclosed.

FIELD

Embodiments described herein generally relate to power management.

BACKGROUND

Power management is used in many devices and systems to improve powerefficiency, helping to reduce power consumption and/or heat dissipation.For battery-powered mobile devices and systems, power management canhelp extend operation.

Some platform-level power management has been based on some heuristicscollected on the platform and some guidance given by an operatingsystem. Processor utilization can be used as a rough estimate ofplatform activity. When there is heavy input/output (I/O) activity andlight processor utilization, however, the platform will be put intolower power states, impacting I/O performance. Indeed, as a platformgoes into deeper power states, its response latency to break events likedirect memory access (DMA) accesses and interrupts increases. Althoughmany I/O devices are designed to tolerate some fixed minimum responselatency from the platform, this can effectively limit the depth of powerstates which the platform may enter. The platform would compromisefunctionality and/or performance if the platform entered a deeper powerstate that increased its response latency beyond the fixed minimum anI/O device could tolerate.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are illustrated by way of example and not limitation in thefigures of the accompanying drawings, in which like references indicatesimilar elements and in which:

FIG. 1 illustrates, for one embodiment, a block diagram of an examplesystem to perform power management based at least in part on servicelatency reporting from one or more downstream devices;

FIG. 2 illustrates, for one embodiment, a block diagram of a downstreamdevice to report service latency to an upstream device;

FIG. 3 illustrates, for one embodiment, an example flow diagram for adownstream device to report service latency to an upstream device;

FIG. 4 illustrates, for one embodiment, a block diagram of a downstreamdevice to report service latency to an upstream device in accordancewith a first technique;

FIG. 5 illustrates, for one embodiment, an example flow diagram for adownstream device to report service latency to an upstream device inaccordance with the first technique;

FIG. 6 illustrates, for one embodiment, a block diagram of a downstreamdevice to report service latency to an upstream device in accordancewith a second technique;

FIG. 7 illustrates, for one embodiment, an example flow diagram for adownstream device to report service latency to an upstream device inaccordance with the second technique;

FIG. 8 illustrates, for one embodiment, an example diagram for adownstream device to report service latency to an upstream device inaccordance with the second technique;

FIG. 9 illustrates, for one embodiment, a block diagram of a downstreamdevice to report service latency to an upstream device in accordancewith a third technique;

FIG. 10 illustrates, for one embodiment, an example flow diagram for adownstream device to report service latency to an upstream device inaccordance with the third technique;

FIG. 11 illustrates, for one embodiment, an example diagram for adownstream device to report service latency to an upstream device inaccordance with the third technique;

FIG. 12 illustrates, for one embodiment, an example flow diagram for adownstream device to report service latency to an upstream device inaccordance with a fourth technique;

FIG. 13 illustrates, for one embodiment, a block diagram of a downstreamdevice to report service latency to an upstream device in accordancewith a fifth technique;

FIG. 14 illustrates, for one embodiment, an example flow diagram for adownstream device to report service latency to an upstream device inaccordance with the fifth technique;

FIG. 15 illustrates, for one embodiment, a block diagram of a downstreamdevice to report service latency to an upstream device in accordancewith a sixth technique;

FIG. 16 illustrates, for one embodiment, an example flow diagram for adownstream device to report service latency to an upstream device inaccordance with the sixth technique; and

FIG. 17 illustrates, for one embodiment, an example diagram for adownstream device to report service latency to an upstream device inaccordance with the sixth technique.

The figures of the drawings are not necessarily drawn to scale.

DETAILED DESCRIPTION

The following detailed description sets forth example embodiments ofapparatuses, methods, and systems relating to downstream device servicelatency reporting for power management. Features, such as structure(s),function(s), and/or characteristic(s) for example, are described withreference to one embodiment as a matter of convenience; variousembodiments may be implemented with any suitable one or more describedfeatures.

FIG. 1 illustrates an example system 100 comprising one or moreprocessors 110 and platform control logic 120 coupled to processor(s)110. Processor(s) 110 for one embodiment may have one or more processorpower management controllers (PPMCs) 112 to help improve powerefficiency for processor(s) 110. Platform control logic 120 for oneembodiment may have a platform controller power management controller(PCPMC) 122 to help improve power efficiency for system 100. PCPMC 122for one embodiment may, for example, manage one or more components ofsystem 100 to enter into one of a plurality of lower power or sleepstates when the component is less active or idle.

PCPMC 122 for one embodiment may help coordinate power management forcomponents of system 100 to help improve power efficiency. PCPMC 122 forone embodiment may, for example, coordinate with one or more PPMCs 112for such PPMC(s) 112 and PCPMC 122 to better identify the depth of lowerpower states which one or more components may enter yet still beresponsive to one or more other components with reduced concern for lostfunctionality and/or performance.

PCPMC 122 for one embodiment may receive from one or more downstreamdevices, such as device 132 for example, data corresponding to a servicelatency for that device. PCPMC 122 for one embodiment may manage powerbased at least in part on the received data and therefore based at leastin part on the corresponding service latency. The service latency forone embodiment may be a service latency tolerance for the device. Theservice latency for one embodiment may be based at least in part on themaximum latency the device may tolerate without adversely affectingfunctionality or performance of the device. The service latency for oneembodiment may correspond to a level relating to activity for at least aportion of the device. PCPMC 122 for one embodiment may thereforereceive over time different service latencies from the device dependingat least in part on the activity level for at least a portion of thedevice. PCPMC 122 for one embodiment may better identify the depth oflower power states which one or more components of system 100 may enterand still be responsive to the device with reduced concern for lostfunctionality and/or performance.

One or more PPMCs 112 for one embodiment may coordinate with PCPMC 122and also manage power based at least in part on a service latency for adownstream device. PCPMC 122 for one embodiment may transmit receiveddata corresponding to a service latency for a device to one or morePPMCs 112 for such PPMC(s) 112 to manage power based at least in part onthat service latency. One or more PPMCs 112 for one embodiment mayindirectly manage power based at least in part on a service latency fora device based at least in part on how PCPMC 122 manages power based atleast in part on that service latency.

Platform control logic 120 for one embodiment may comprise one or moreinterface controllers 124 to communicate with one or more devices, suchas devices 132 and 134. Such interface controller(s) 124 may compriseany suitable logic to interface with one or more devices in any suitablemanner. One or more interface controllers 124 for one embodiment may becompatible with any suitable one or more standard specifications suchas, for example and without limitation, any suitable Universal SerialBus (USB) specification (e.g., USB Specification Revision 2.0, Apr. 27,2000; USB 2.0 Link Power Management Addendum Engineering Change Notice,Jul. 16, 2007; USB 3.0 Specification Revision 1.0, Nov. 12, 2008) and/orany suitable Peripheral Component Interface (PCI) or PCI Express (PCIe)specification (e.g., PCI Express Base Specification Revision 1.0, Jul.22, 2002; PCI Express Base Specification Revision 2.0, Jan. 15, 2007).

One or more interface controllers 124 for one embodiment may receivefrom one or more downstream devices data corresponding to a servicelatency for the device and transmit such data to PCPMC 122. One or moreinterface controllers 124 for one embodiment may include an interfacecontroller power management controller (ICPMC) 126 to help improve powerefficiency for the interface controller 124 and/or for the connection orlink to one or more devices. One or more ICPMCs 126 for one embodimentmay receive from one or more devices data corresponding to a servicelatency for the device and manage power based at least in part on thereceived data and therefore based at least in part on the correspondingservice latency. PCPMC 122 for one embodiment may indirectly managepower based at least in part on a service latency for a device based atleast in part on how one or more ICPMCs 126 manage power based at leastin part on that service latency.

Interface controller(s) 124 for one embodiment may receive datacorresponding to a service latency for a device, such as device 136 forexample, downstream from another device, such as device 134 for example.Device 134 for one embodiment may receive from device 136 datacorresponding to a service latency for device 136 and transmit such datato interface controller(s) 124. Device 134 for one embodiment mayreceive from device 136 data corresponding to a service latency fordevice 136 and manage power for device 134 based at least in part on thereceived data and therefore based at least in part on the correspondingservice latency. A corresponding ICPMC 126 for one embodiment mayindirectly manage power based at least in part on a service latency fordevice 136 based at least in part on how device 134 manages power basedat least in part on that service latency.

For one embodiment, power may be managed in system 100 based at least inpart on a service latency for a device as described in U.S. patentapplication Ser. No. 12/006,251, entitled LATENCY BASED PLATFORMCOORDINATION, and filed Dec. 31, 2007; U.S. patent application Ser. No.12/059,992, entitled PLATFORM POWER MANAGEMENT BASED ON LATENCYGUIDANCE, and filed Mar. 31, 2008; and/or U.S. patent application Ser.No. 12/146,873, entitled COORDINATED LINK POWER MANAGEMENT, and filedJun. 26, 2008.

As illustrated in FIG. 1, system 100 for one embodiment may also haveone or more input devices 140, one or more displays 150, volatile memory160, one or more non-volatile memory and/or storage devices 170, and oneor more communications interfaces 180.

Processor(s) 110 for one embodiment may include one or more memorycontrollers to provide an interface to volatile memory 160. Volatilememory 160 may be used to load and store data and/or instructions, forexample, for system 100. Volatile memory 160 may include any suitablevolatile memory, such as suitable dynamic random access memory (DRAM)for example. Processor(s) 110 for one embodiment may use PPMC(s) 112 tohelp manage power for volatile memory 160.

Although described as residing with processor(s) 110, one or more memorycontrollers for one embodiment may reside with platform control logic120, allowing platform control logic 120 to communicate with volatilememory 160 directly.

Platform control logic 120 for one embodiment may include any suitableinterface controllers, including interface controller(s) 124, to providefor any suitable communications link to processor(s) 110 and/or to anysuitable device or component in communication with platform controllogic 120. Platform control logic 120 for one embodiment may use PCPMC122 to help manage power for any suitable one or more devices and/orcomponents in communication with platform control logic 120.

Platform control logic 120 for one embodiment may include one or moregraphics controllers to provide an interface to display(s) 150.Display(s) 150 may include any suitable display, such as a cathode raytube (CRT) or a liquid crystal display (LCD) for example. One or moregraphics controllers for one embodiment may alternatively be external toplatform control logic 120.

Platform control logic 120 for one embodiment may include one or moreinput/output (I/O) controllers to provide an interface to inputdevice(s) 140, non-volatile memory and/or storage device(s) 170, andcommunications interface(s) 180.

Input device(s) 140 may include any suitable input device(s), such as akeyboard, a mouse, and/or any other suitable cursor control device.

Non-volatile memory and/or storage device(s) 170 may be used to storedata and/or instructions, for example. Non-volatile memory and/orstorage device(s) 170 may include any suitable non-volatile memory, suchas flash memory for example, and/or may include any suitablenon-volatile storage device(s), such as one or more hard disk drives(HDDs), one or more compact disc (CD) drives, and/or one or more digitalversatile disc (DVD) drives for example.

Communications interface(s) 180 may provide an interface for system 100to communicate over one or more networks and/or with any other suitabledevice. Communications interface(s) 180 may include any suitablehardware and/or firmware. Communications interface(s) 180 for oneembodiment may include, for example, a network adapter, a wirelessnetwork adapter, a telephone modem, and/or a wireless modem. Forwireless communications, communications interface(s) 180 for oneembodiment may use one or more antennas 182.

Downstream devices 132, 134, and 136 for one embodiment may be anysuitable device that may be coupled to platform control logic 120 suchas, for example and without limitation, a suitable input device 140, asuitable non-volatile memory or storage device 170, a suitablecommunications interface 180, or any other suitable I/O device. Examplesof a downstream device may include, without limitation, a cursor controldevice, a storage drive, a storage device, a hub device, a networkrouter or switch, a battery charging device, a printer, a scanner, acamcorder, a camera, a media player, a cellular telephone, a smartphone, a mobile internet device, and a computer system such as adesktop, notebook, netbook, or other computer system.

Although described as residing with platform control logic 120, one ormore controllers of platform control logic 120, including one or moreinterface controllers 124, for one embodiment may reside with one ormore processors 110, allowing a processor 110 to communicate with one ormore devices or components directly. One or more controllers of platformcontrol logic 120, including one or more interface controllers 124, forone embodiment may be integrated on a single die with at least a portionof one or more processors 110. One or more controllers of platformcontrol logic 120, including one or more interface controllers 124, forone embodiment may be packaged with one or more processors 110.

Service Latency Reporting

FIG. 2 illustrates, for one embodiment, a device 200 that may reportservice latency for one or more upstream devices to manage power basedat least in part on the service latency. Device 200 for one embodimentmay correspond, for example, to downstream device 132 or 134 of FIG. 1and report service latency for system 100 to manage power based at leastin part on the service latency. Device 200 for one embodiment maycorrespond, for example, to downstream device 136 of FIG. 1 and reportservice latency for device 134 and/or system 100 to manage power basedat least in part on the service latency.

As illustrated in FIG. 2, device 200 for one embodiment may comprisedevice control logic 202, interface control logic 204, transitionidentification logic 206, and service latency reporting logic 208.Device control logic 202, interface control logic 204, transitionidentification logic 206, and service latency reporting logic 208 mayeach be implemented in any suitable manner using, for example, anysuitable hardware, any suitable hardware performing any suitablefirmware, any suitable hardware performing any suitable software, or anysuitable combination of such implementations. For one embodiment, anysuch firmware and/or software may be stored in any suitable computerreadable storage medium or media of device 200. Device 200 for oneembodiment may also comprise other suitable logic, circuitry, and/or oneor more components to implement any suitable functionality for device200.

Device control logic 202 for one embodiment may help control thefunctionality of device 200 and may communicate with one or moreupstream devices using interface control logic 204 to providefunctionality to one or more components of such device(s).

Interface control logic 204 may be coupled to device control logic 202to transmit and/or receive data for device 200 in any suitable manner.Interface control logic 204 for one embodiment may be compatible withany suitable one or more standard specifications such as, for exampleand without limitation, any suitable Universal Serial Bus (USB)specification and/or any suitable Peripheral Component Interface (PCI)or PCI Express (PCIe) specification.

Transition identification logic 206 for one embodiment may identify atransition for at least a portion of device 200 from one state toanother, different state in any suitable manner. Such states for oneembodiment may correspond to different levels relating to activity forat least a portion of device 200. Transition identification logic 206for one embodiment may identify a transition for at least a portion ofdevice control logic 202 from one state to another, different state.Transition identification logic 206 for one embodiment may identify thatat least a portion of device 200 is about to transition from one stateto another, different state. Transition identification logic 206 for oneembodiment may identify that at least a portion of device 200 hasalready transitioned from one state to another, different state.

Service latency reporting logic 208 for one embodiment may transmit toan upstream device data corresponding to a service latency in responseto identification of a transition by transition identification logic206. Service latency reporting logic 208 for one embodiment may becoupled to receive identification of a state transition from transitionidentification logic 206 in any suitable manner. Service latencyreporting logic 208 for one embodiment may be coupled to transmit datacorresponding to a service latency in any suitable manner usinginterface control logic 204.

Service latency reporting logic 208 for one embodiment may identify aservice latency in any suitable manner. The service latency for oneembodiment may be a service latency tolerance for device 200. Theservice latency for one embodiment may be based at least in part on themaximum latency device 200 may tolerate without adversely affectingfunctionality or performance of device 200. The service latency for oneembodiment may correspond to a new state for at least a portion ofdevice 200.

Service latency reporting logic 208 for one embodiment may identify anew service latency based at least in part on a prior or current servicelatency and identification of a state transition. Service latencyreporting logic 208 for one embodiment may identify a new servicelatency based at least in part on a new state. Service latency reportinglogic 208 for one embodiment may identify the new state based at leastin part on a prior or current state. Service latency reporting logic 208for one embodiment may receive identification of a new state fromtransition identification logic 206 in any suitable manner.

As at least a portion of device 200 may continue to transition betweenstates, service latency reporting logic 208 for one embodiment maycontinue to identify new service latencies and transmit datacorresponding to such service latencies. Service latency reporting logic208 for one embodiment may optionally not transmit data corresponding toa new service latency, for example if the new service latency is thesame as a prior or current service latency. Service latency reportinglogic 208 for one embodiment may transmit data corresponding to a newservice latency in response to one or more but not all transitionsbetween states.

FIG. 3 illustrates an example flow diagram 300 for one embodiment ofdevice 200 to report service latency to an upstream device. Asillustrated in FIG. 3, at least a portion of device 200 may be in afirst state for block 302. Service latency reporting logic 208 for block304 may transmit data corresponding to a first service latency thatcorresponds to the first state. Transition identification logic 206 mayidentify for block 306 whether at least a portion of device 200 hastransitioned to or is about to transition to a second, different state.If so, service latency reporting logic 208 for block 308 may transmitdata corresponding to a second service latency that corresponds to thesecond state. Transition identification logic 206 may identify for block310 whether at least a portion of device 200 has transitioned to or isabout to transition to the first state. If so, service latency reportinglogic 208 for block 304 may transmit data corresponding to the firstservice latency. Service latency reporting logic 208 and transitionidentification logic 206 for one embodiment may continue to performoperations for blocks 304-310 in this manner.

Although described in connection with first and second service latenciescorresponding to first and second states, service latency reportinglogic 208 for one embodiment may transmit data for service latenciescorresponding to more than two states.

Service Latency Based at Least in Part on Activity Level

Transition identification logic 206 for one embodiment may identify atransition for at least a portion of device 200 between statescorresponding to different activity levels. Service latency reportinglogic 208 for one embodiment may transmit data corresponding to a lowerservice latency for a transition to a state corresponding to a higheractivity level and may transmit data corresponding to a higher servicelatency for a transition to a state corresponding to a lower activitylevel. Transition identification logic 206 for one embodiment mayidentify a transition for at least a portion of device 200 between anactive state where device 200 has data communications with an upstreamdevice and an idle state where device 200 does not have datacommunications with an upstream device.

At least a portion of device 200 for one embodiment may at some timesfrequently transition between different states. As one example, at leasta portion of device 200 for one embodiment may have bursts of activityand therefore at some times frequently transition into and out from alow activity or idle state. Service latency reporting logic 208 for oneembodiment may wait a predetermined period of time after identificationof a state transition before transmitting data corresponding to aservice latency to help identify whether at least a portion of device200 is more likely to remain in a new state. In this manner, servicelatency reporting logic 208 for one embodiment may avoid frequentlytransmitting data corresponding to different service latencies thatcould otherwise reduce the effectiveness of power management for one ormore upstream devices.

Service latency reporting logic 208 for one embodiment may wait apredetermined period of time after identification of a transition to astate corresponding to a service latency higher than a current servicelatency but not after identification of a transition to a statecorresponding to a service latency lower than a current service latency.As one example, service latency reporting logic 208 for one embodimentmay wait a predetermined period of time after identification of atransition to a low activity or idle state but not after identificationof a transition to a higher activity state.

As illustrated in FIG. 4, service latency reporting logic 208 for oneembodiment may have a timer 402 to identify a wait time afteridentification of a new state transition. Service latency reportinglogic 208 for one embodiment may compare the wait time with apredetermined threshold and wait until the wait time equals or exceedsthe predetermined threshold before transmitting data corresponding to aservice latency for the new state transition. If transitionidentification logic 206 identifies a newer state transition before thepredetermined threshold has been reached, service latency reportinglogic 208 for one embodiment may restart timer 402 for the newertransition. Service latency reporting logic 208 for one embodiment mayinstead, depending for example at least in part on the state for thenewer transition, reset timer 402 and transmit data corresponding to aservice latency for the newer transition.

FIG. 5 illustrates an example flow diagram 500 for one embodiment ofdevice 200 to report service latency to an upstream device. Asillustrated in FIG. 5, at least a portion of device 200 may be in a lowactivity or idle state for block 502. Service latency reporting logic208 for block 504 may transmit data corresponding to a first servicelatency. Transition identification logic 206 may identify for block 506whether at least a portion of device 200 has transitioned to or is aboutto transition to a higher activity state. If so, service latencyreporting logic 208 for block 508 may transmit data corresponding to asecond service latency. Transition identification logic 206 may identifyfor block 510 whether at least a portion of device 200 has transitionedto or is about to transition to the low activity or idle state. If so,service latency reporting logic 208 for block 512 may wait apredetermined period of time. If at least a portion of device 200 isstill in the low activity or idle state for block 514, service latencyreporting logic 208 for block 504 may transmit data corresponding to thefirst service latency. Service latency reporting logic 208 andtransition identification logic 206 for one embodiment may continue toperform operations for blocks 504-514 in this manner.

Although described in connection with idle and active service latenciescorresponding to low activity/idle and active states, service latencyreporting logic 208 for one embodiment may transmit data for servicelatencies corresponding to one or more additional states, such as one ormore states corresponding to different levels of activity.

Service Latency Based at Least in Part on Device Buffering

Device 200 for one embodiment may receive data from another device fortransmission to an upstream device. As illustrated in FIG. 6, devicecontrol logic 202 for one embodiment may include a buffer 602 to receivedata from another device over any suitable communications link,including any suitable wireless link, for subsequent transmission frombuffer 602 to an upstream device using interface control logic 204.Device 200 for one embodiment may be, for example, an Ethernet NetworkInterface Controller (NIC).

For one embodiment when at least a portion of device 200 is in a lowactivity or idle state, device 200 may transmit data corresponding to aservice latency based at least in part on an available capacity ofbuffer 602 for device 200 to receive data. In this manner, an upstreamdevice for one embodiment can remain able to respond within the servicelatency period to start receiving data from buffer 602 before theavailable capacity of buffer 602 fills. If the service latency wereotherwise higher, an upstream device might possibly enter a deeper,lower power state and not respond in time, allowing buffer 602 tooverflow and incurring performance loss to have lost data retransmitted.

Transition identification logic 206 for one embodiment may identify atransition from the low activity or idle state to an active state toreceive data in and retransmit data from buffer 602. Service latencyreporting logic 208 for one embodiment may then transmit datacorresponding to a lower service latency to the upstream device. Servicelatency reporting logic 208 for one embodiment may transmit datacorresponding to a service latency based at least in part on a reservecapacity of buffer 602 for device 200 to receive data. In this manner,device 200 may continue to receive data in buffer 602 as data starts tobe transmitted from buffer 602 to the upstream device.

FIG. 7 illustrates an example flow diagram 700 for one embodiment ofdevice 200 to report service latency to an upstream device. Asillustrated in FIG. 7, at least a portion of device 200 may be in a lowactivity or idle state for block 702. Service latency reporting logic208 for block 704 may transmit data corresponding to a service latencybased at least in part on an available buffer capacity. Transitionidentification logic 206 may identify for block 706 whether at least aportion of device 200 has transitioned to or is about to transition toan active state to receive and retransmit data from another device. Ifso, service latency reporting logic 208 for block 708 may transmit datacorresponding to a service latency based at least in part on a reservebuffer capacity. Transition identification logic 206 may identify forblock 710 whether at least a portion of device 200 has transitioned toor is about to transition to the low activity or idle state. If so,service latency reporting logic 208 for block 704 may transmit datacorresponding to the service latency based at least in part on anavailable buffer capacity. Service latency reporting logic 208 for oneembodiment may optionally wait a predetermined period of time afteridentification of a state transition for block 710 before transmittingdata for block 704. Service latency reporting logic 208 and transitionidentification logic 206 for one embodiment may continue to performoperations for blocks 704-710 in this manner.

Service latency reporting logic 208 for one embodiment may account fordata rate and/or performance requirements for the upstream device inreceiving data to identify a service latency for blocks 704 and 708.

Although described in connection with service latencies corresponding tolow activity/idle and active states, service latency reporting logic 208for one embodiment may transmit data for service latencies correspondingto one or more additional states. For one embodiment, service latencyreporting logic 208 may transmit data for service latenciescorresponding to states that correspond to different ranges of datarates at which device 200 may receive data from another device. For oneembodiment, service latency reporting logic 208 may transmit data forservice latencies corresponding to states that correspond to differentperformance requirements for the upstream device in receiving data.

FIG. 8 illustrates an example diagram for one embodiment of device 200to report service latency to an upstream device. As illustrated in FIG.8, buffer 602 receives network data at 802. Prior to receiving networkdata, device 200 was in an idle state and transmitted to upstreamplatform components data corresponding to a latency tolerance report(LTR) of 500 microseconds (μs) which is based at least in part on anavailable capacity of buffer 602 and the rate at which network data isreceived into buffer 602. When device 200 initially receives networkdata, device 200 transitions to, or is about to transition to, an activestate and transmits data corresponding to an LTR of 100 μs at 802 toupstream platform components. The 100 μs LTR is based at least in parton a reserve capacity of buffer 602 and the rate at which network datais received into buffer 602. The 100 μs LTR takes effect within theprior 500 μs LTR period while buffer 602 receives network data.

Upstream platform components respond within the 100 μs LTR at 804, 806,and 808 to receive data from buffer 602. When device 200 no longerreceives network data at 810, device 200 transitions to an idle state,waits a predetermined amount of time illustrated as Timeout, andtransmits data corresponding to the 500 μs LTR at 812 to upstreamplatform components. As illustrated in FIG. 8, upstream platformcomponents enter various power states based at least in part on the LTRsand responses to receive data from buffer 602.

Service Latency Based at Least in Part on Power State

Transition identification logic 206 for one embodiment may identify atransition for at least a portion of device 200 between statescorresponding to different power levels. Service latency reporting logic208 for one embodiment may transmit data corresponding to a lowerservice latency for a transition to a higher power state and maytransmit data corresponding to a higher service latency for a transitionto a lower power state.

As illustrated in FIG. 9, device control logic 202 for one embodimentmay include a device power management controller (DPMC) 902 to helpimprove power efficiency for device 200. DPMC 902 for one embodimentmay, for example, manage at least a portion of device 200 to enter intoone or more lower power or sleep states when less active or idle.

FIG. 10 illustrates an example flow diagram 1000 for one embodiment ofdevice 200 to report service latency to an upstream device. Asillustrated in FIG. 10, at least a portion of device 200 may be in alower power state for block 1002. Service latency reporting logic 208for block 1004 may transmit data corresponding to a first servicelatency that corresponds to the lower power state. Transitionidentification logic 206 may identify for block 1006 whether at least aportion of device 200 has transitioned to or is about to transition to ahigher power state. If so, service latency reporting logic 208 for block1008 may transmit data corresponding to a second service latency thatcorresponds to the higher power state. Transition identification logic206 may identify for block 1010 whether at least a portion of device 200has transitioned to or is about to transition to the lower power state.If so, service latency reporting logic 208 for block 1004 may transmitdata corresponding to the first service latency. Service latencyreporting logic 208 and transition identification logic 206 for oneembodiment may continue to perform operations for blocks 1004-1010 inthis manner.

Although described in connection with first and second service latenciescorresponding to lower and higher power states, service latencyreporting logic 208 for one embodiment may transmit data for servicelatencies corresponding to more than two power states.

FIG. 11 illustrates an example diagram for one embodiment of device 200to report service latency to an upstream device. Device 200 for FIG. 11may be, for example, a wireless local area network (WLAN) device. Asillustrated in FIG. 11, DPMC 902 may power manage a radio of device 200and enter into a lower power or sleep state at 1102. Device 200 for FIG.11 for one embodiment may use a wireless protocol that supports powermanagement features to allow device 200 to indicate to an access pointor base station, for example, that device 200 is entering a lower powerstate. No data would then be transmitted to device 200 when in the lowerpower state.

Prior to entering the lower power state, device 200 was in a higherpower state and transmitted to an upstream device data corresponding toa latency of 100 microseconds (μs) at 1104. When device 200 is totransition to a lower power state, device 200 transmits to the upstreamdevice data corresponding to a latency of 1 millisecond (ms) at 1106.When device 200 is ready to move data and is to transition to a higherpower state, device 200 transmits to the upstream device datacorresponding to a latency of 100 μs at 1108.

Service Latency Based at Least in Part on Task Performance

Transition identification logic 206 for one embodiment may identify atransition for at least a portion of device 200 between statescorresponding to different task performance levels. Service latencyreporting logic 208 for one embodiment may transmit data correspondingto a lower service latency for a transition to a higher task performancestate and may transmit data corresponding to a higher service latencyfor a transition to a lower task performance state. A higher taskperformance state for one embodiment may correspond, for example, to astate with one or more pending tasks. A lower task performance state forone embodiment may correspond, for example, to a state with no pendingtasks or completion of one or more tasks.

Device control logic 202 for one embodiment may perform one or moretasks for device 200. Device control logic 202 for one embodiment mayinitiate performance of one or more tasks on its own. Device controllogic 202 for one embodiment may perform one or more tasks at therequest of another device. Device control logic 202 for one embodimentmay perform one or more tasks at the request of an upstream device.

FIG. 12 illustrates an example flow diagram 1200 for one embodiment ofdevice 200 to report service latency to an upstream device. Asillustrated in FIG. 12, at least a portion of device 200 may be in alower task performance state for block 1202. Service latency reportinglogic 208 for block 1204 may transmit data corresponding to a firstservice latency that corresponds to the lower task performance state.Transition identification logic 206 may identify for block 1206 whetherat least a portion of device 200 has transitioned to or is about totransition to a higher task performance state. If so, service latencyreporting logic 208 for block 1208 may transmit data corresponding to asecond service latency that corresponds to the higher task performancestate. Transition identification logic 206 may identify for block 1210whether at least a portion of device 200 has transitioned to or is aboutto transition to the lower task performance state. If so, servicelatency reporting logic 208 for block 1204 may transmit datacorresponding to the first service latency. Service latency reportinglogic 208 and transition identification logic 206 for one embodiment maycontinue to perform operations for blocks 1204-1210 in this manner.

Although described in connection with first and second service latenciescorresponding to lower and higher task performance states, servicelatency reporting logic 208 for one embodiment may transmit data forservice latencies corresponding to more than two states corresponding todifferent task performance levels.

Externally Controlled Service Latency

Service latency reporting logic 208 for one embodiment may transmit toan upstream device data corresponding to a service latency identified bythe upstream device. Device 200 for one embodiment may have a servicelatency that may be identified by an upstream device, for example, ifdevice 200 does not have a stringent service latency or has servicelatencies that vary infrequently. Device 200 for one embodiment may havea service latency that may be identified by an upstream device, forexample, if device 200 is to perform one or more tasks scheduled by anupstream device. The upstream device for one embodiment may identify alower service latency for device 200 before tasks are scheduled and ahigher service latency for device 200 when all scheduled tasks arecompleted.

The upstream device for one embodiment may transmit to device 200 datacorresponding to a service latency identified by the upstream device.The upstream device for one embodiment may perform software to identifya service latency for device 200. Such software for one embodiment maybe, for example, driver software for device 200.

As illustrated in FIG. 13, service latency reporting logic 208 for oneembodiment may include memory 1302 to receive data corresponding to aservice latency from an upstream device. For one embodiment, at least aportion of memory 1302 may be mapped into memory space of an upstreamdevice. Memory 1302 for one embodiment may include one or moreregisters. Memory 1302 for one embodiment may be a memory mappedinput/output (MMIO) register.

FIG. 14 illustrates an example flow diagram 1400 for one embodiment ofdevice 200 to report service latency to an upstream device. Asillustrated in FIG. 14, service latency reporting logic 208 for block1402 may receive from an upstream device data corresponding to a servicelatency identified by the upstream device. The upstream device for oneembodiment may transmit such data in performing software. Servicelatency reporting logic 208 for block 1404 may transmit to the upstreamdevice data corresponding to a service latency based at least in part onthe data received for block 1402. Service latency reporting logic 208for one embodiment may transmit data for block 1404 to a powermanagement controller of the upstream device.

Service Latency Based at Least in Part on Periodic Transitions

At least a portion of device 200 for one embodiment may transition froma first state to a second, different state at substantially fixed timeintervals. At least a portion of device 200 for one embodiment maytransition from a low activity or idle state to a higher activity stateat substantially fixed time intervals, returning to the low activity oridle state prior to expiration of the next time interval. As oneexample, device 200 may communicate with an upstream device atsubstantially fixed time intervals.

As illustrated in FIG. 15, transition identification logic 206 for oneembodiment may have a timer 1502 to identify the expiration of a fixedtime interval after identification of a transition for at least aportion of device 200 from a first state to a second, different state toidentify another transition for at least a portion of device 200 fromthe first state to the second state. For another embodiment, devicecontrol logic 202 may have a timer to control transition of at least aportion of device 200 from the first state to the second state, andtransition identification logic 206 for one embodiment may identify sucha transition for at least a portion of device 200 in any suitablemanner.

FIG. 16 illustrates an example flow diagram 1600 for one embodiment ofdevice 200 to report service latency to an upstream device. Asillustrated in FIG. 16, at least a portion of device 200 may be in afirst state for block 1602. Service latency reporting logic 208 forblock 1604 may transmit data corresponding to a first service latencythat corresponds to the first state. Transition identification logic 206may identify for block 1606 whether at least a portion of device 200 hastransitioned to or is about to transition to a second state. If so,service latency reporting logic 208 for block 1608 may transmit datacorresponding to a second service latency that corresponds to the secondstate. Transition identification logic 206 may identify for block 1610whether at least a portion of device 200 has transitioned to or is aboutto transition to the first state. If so, service latency reporting logic208 for block 1612 may transmit data corresponding to the first servicelatency. Transition identification logic 206 may identify for block 1614whether at least a portion of device 200 has transitioned to or is aboutto transition to the second state. For one embodiment, suchidentification may be made based at least in part on expiration of afixed time interval after a prior identification of a transition fromthe first state to the second state. If so for block 1614, servicelatency reporting logic 208 for block 1608 may transmit datacorresponding to the second service latency. Service latency reportinglogic 208 and transition identification logic 206 for one embodiment maycontinue to perform operations for blocks 1608-1614 in this manner.

FIG. 17 illustrates an example diagram for one embodiment of device 200to report service latency to an upstream device. Device 200 for FIG. 17may transition from an idle state to a higher activity state atsubstantially fixed time intervals, returning to the idle state prior toexpiration of the next time interval. Device 200 for FIG. 17 may be, forexample, a voice over internet protocol (VOIP) device.

As illustrated in FIG. 17, device 200 at 1702 may transition from ahigher activity state, represented by a transfer of data between device200 and an upstream device, to an idle state and transmit to theupstream device data corresponding to a 1 millisecond (ms) servicelatency. Device 200 at 1704 may transmit to the upstream device datacorresponding to a 20 microsecond (μs) service latency when device 200is about to again enter the higher activity state. As device 200 is toenter the higher activity state at substantially 20 ms time intervals,device 200 may transmit to the upstream device data corresponding to a20 microsecond (μs) service latency at substantially 20 ms timeintervals.

In the foregoing description, example embodiments have been described.Various modifications and changes may be made to such embodimentswithout departing from the scope of the appended claims. The descriptionand drawings are, accordingly, to be regarded in an illustrative ratherthan a restrictive sense.

What is claimed is:
 1. An apparatus comprising: first logic to identifya transition for at least a portion of a downstream device from a firststate to a second, different state, wherein the first and second statescorrespond to different levels relating to activity for at least aportion of the downstream device; and second logic to transmit to anupstream device data corresponding to a service latency in response tothe identified transition for one or more upstream devices to managepower based at least in part on the service latency.
 2. The apparatus ofclaim 1, wherein the second logic is to wait a predetermined period oftime after identification of the transition before transmitting thedata.
 3. The apparatus of claim 2, wherein the second state is an idlestate.
 4. The apparatus of claim 1, wherein the second state is an idlestate and the service latency is based at least in part on an availablecapacity of a buffer for the downstream device to receive data.
 5. Theapparatus of claim 1, wherein the second state is an active state andthe service latency is based at least in part on a reserve capacity of abuffer for the downstream device to receive data.
 6. The apparatus ofclaim 1, wherein the second state is a lower power state relative to thefirst state.
 7. The apparatus of claim 1, wherein the first statecorresponds to the performance of one or more tasks by the downstreamdevice and the second state corresponds to completion of one or moretasks by the downstream device.
 8. The apparatus of claim 1, wherein thesecond logic is to transmit to an upstream device data corresponding toa service latency identified by the upstream device.
 9. The apparatus ofclaim 1, wherein at least a portion of the downstream device is totransition from the first state to the second state at substantiallyfixed time intervals.
 10. The apparatus of claim 1, wherein the firstlogic is to identify that at least a portion of the downstream device isabout to transition from the first state to the second state.
 11. Theapparatus of claim 1, wherein the first logic is to identify that atleast a portion of the downstream device has transitioned from the firststate to the second state.
 12. A method comprising: identifying atransition for at least a portion of a downstream device from a firststate to a second, different state, wherein the first and second statescorrespond to different levels relating to activity for at least aportion of the downstream device; and transmitting to an upstream devicedata corresponding to a service latency in response to the identifiedtransition for one or more upstream devices to manage power based atleast in part on the service latency.
 13. The method of claim 12,comprising waiting a predetermined period of time after identificationof the transition before transmitting the data.
 14. The method of claim12, wherein the second state is an idle state and the service latency isbased at least in part on an available capacity of a buffer for thedownstream device to receive data.
 15. The method of claim 12, whereinthe second state is a lower power state relative to the first state. 16.The method of claim 12, wherein the first state corresponds to theperformance of one or more tasks by the downstream device and the secondstate corresponds to completion of one or more tasks by the downstreamdevice.
 17. The method of claim 12, wherein the transmitting includestransmitting to an upstream device data corresponding to a servicelatency identified by the upstream device.
 18. The method of claim 12,comprising transitioning by at least a portion of the downstream devicefrom the first state to the second state at substantially fixed timeintervals.
 19. A downstream device comprising: first logic to identify atransition for at least a portion of the downstream device from a firststate to a second, different state, wherein the first and second statescorrespond to different levels relating to activity for at least aportion of the downstream device; second logic to transmit to anupstream device data corresponding to a service latency in response tothe identified transition for one or more upstream devices to managepower based at least in part on the service latency; and third logic tohelp control functionality of the downstream device.
 20. The downstreamdevice of claim 19, wherein the second logic is to wait a predeterminedperiod of time after identification of the transition beforetransmitting the data.
 21. The downstream device of claim 19, whereinthe second state is an idle state and the service latency is based atleast in part on an available capacity of a buffer for the downstreamdevice to receive data.
 22. The downstream device of claim 19, whereinthe second state is a lower power state relative to the first state. 23.The downstream device of claim 19, wherein the first state correspondsto the performance of one or more tasks by the downstream device and thesecond state corresponds to completion of one or more tasks by thedownstream device.
 24. The downstream device of claim 19, wherein thesecond logic is to transmit to an upstream device data corresponding toa service latency identified by the upstream device.
 25. The downstreamdevice of claim 19, wherein at least a portion of the downstream deviceis to transition from the first state to the second state atsubstantially fixed time intervals.